In a presence network, such as the presence service proposed by the Open Mobile Alliance (OMA) standards or a Parlay X-based network, a presence entity, such as a Presentity in an OMA-based system, is a logical entity associated with a Presence User (for example, representing a human or a communication device) that has presence information associated with it. A Presence Source associated with the presence entity provides presence information about the presence entity to a Presence Server, and a Watcher requests presence information about the presence entity from the Presence Server. For example, in an OMA-based system, a Presence Source, implemented in a communication device operated by a first Presence User, may publish presence information to the Presence Server by conveying a Session Initiation Protocol SIP (Session Initiation Protocol) PUBLISH message comprising the presence information to the Presence Server. The presence information includes a current state of user status attributes associated with the presence entity, such as Presence Information Elements in an OMA-based system, for example, a location, an availability, a willingness, a mood, an activity, and so on. The Presence Server then stores the current state of the user status attributes in association with the presence entity. In addition, the Presence Server maintains a profile in association with each presence entity, which profile may include access rules that determine which set of Watchers are authorized to see presence information associated with the presence entity.
A second Presence User may wish to know a state of presence information associated with the first Presence User. In order to be informed of the presence information, a Watcher implemented in a second communication device associated with the second Presence User creates a subscription at the Presence Server to watch the first Presence User and/or to watch a group of Presence Users (also called a ‘Resource List’). For example, in an OMA-based system, the Watcher may request to watch by conveying a SIP SUBSCRIBE message to the Presence Server requesting presence information associated with the watched entity (that is, the first User) or group of watched entities (that is, the group of Presences Users). Each subscription has an expiry value associated with it, which expiry value can be requested by a Watcher but overridden by the Presence Server. Prior to the expiration of the expiry value, the Watcher needs to refresh the subscription in order to prevent the subscription from lapsing.
In subscribing to watch a presence entity/group of watched entities, the Watcher may request notification concerning all user status attributes associated with each such presence entity, or may request notification concerning only select user status attributes. If the Watcher is authorized by the Presence Server, for example, by the access rules associated with a presence entity, the Watcher is then provided with a current state of each requested user status attribute, for example, via a SIP NOTIFY message in an OMA-based system.
A Presence Source associated with a presence entity then publishes a presence information update to the Presence Server every time a state of one or more user status attributes changes, regardless of the user status attributes watched by the Watcher/second Presence User. When the Presence Server receives the presence information update, the Presence Server forwards the update to the Watchers that have subscribed to that user status attribute of that presence entity.
In some systems, a Watcher may not know in advance the list of presence entities that may be watched. In such a system, the Watcher may create a new subscription as and when watched entities are added. For example, the Watcher may obtain information about new presence entities through directory updates. As a result, a number of watched entities, and corresponding subscriptions, can be in the range of 150-300 subscriptions per Watcher. Even if Resource Lists are used, the number of Resource Lists and presence entities outside of the Resource Lists, and corresponding subscriptions, may still be in the range of 50-60 subscriptions per Watcher.
Watchers typically refresh their subscriptions just before the subscriptions expire. As a result, subscriptions typically have long expiry values, for example, 3600 seconds (one hour) because when a Watcher goes through a refresh-subscription phase, the Watcher may send a burst of a large set of subscription (SIP SUBSCRIBE) messages, one for each subscription. Such an exchange of messaging can consume significant system capacity in a limited bandwidth communication system, such as a wireless communication system, and can consume excessive communication device power when the first communication device comprises a limited life power supply, such as a battery.
Furthermore, when multiple SIP NOTIFY messages associated with a subscription fail to reach a Watcher, for example, due to deterioration of a quality of the Watcher's, that is, the associated Presence User's, wireless coverage or the associated Presence User roaming outside of an area of wireless coverage, the Presence Server may drop that subscription for the Watcher. In such an instance, until the Watcher refreshes the subscription, the Watcher will not receive SIP NOTIFY messages associated with that subscription even when the associated Presence User regains acceptable coverage and may not even be aware that the subscription has been dropped.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Those skilled in the art will further recognize that references to specific implementation embodiments such as “circuitry” may equally be accomplished via replacement with software instruction executions either on general purpose computing apparatus (e.g., CPU) or specialized processing apparatus (e.g., DSP). It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.